To be honest, I don't know what strong name signing is. Never used it, never needed it. Does it even still exist in the newer .NET Core/5 series? Your change seems to introduce private key material. Is that a good idea in a (public) code repository?

Hello Yves,

please have a look to the following links (which I hope explains the topic):
https://docs.microsoft.com/en-us/dotnet/standard/assembly/strong-named
https://docs.microsoft.com/en-us/dotnet/standard/assembly/strong-named

Strong naming refers to signing an assembly with a key, producing a strong-named assembly. When an assembly is strong-named, it creates a unique identity based on the name and assembly version number, and it can help prevent assembly conflicts.

One important aspect of strong naming is that it's viral: a strong named assembly can only reference other strong named assemblies. If your library isn't strong named, then you have excluded developers who are building an application or library that needs strong naming from using it.

If you are an open-source developer and you want the identity benefits of a strong-named assembly for better compatibility with .NET Framework, consider checking in the private key associated with an assembly to your source control system.

Two examples of other open source projects using strong name signing:
https://github.com/NLog/NLog/tree/master/src
https://github.com/commandlineparser/commandline

If you think signing of Debug builds is also a good idea, (…)

Actually I don't think anything here. I'd just follow your suggestion. It looks plausible in its current form. If you'd prefer to also sign debug builds, please change the PR to not include that line. Otherwise, I'd merge it as-is.

I have enabled Strong Name signing globally and merged latest changes from master.